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ELECTRONIC RECORD MANAGEMENT SYSTEM 
BACKGROUND 

1 . Field of the Invention. 

This invention relates in general to networked computing systems, and more 
particularly, to a system for managing electronic records. 

2. Description of Related Art 

Email is a fast and convenient form of communication in the workplace. It is 
universally transforming the way organizations communicate and is rapidly 
spawning court cases regarding workplace privacy and monitoring, intellectual 
property, network security, electronic commerce, freedom of expression, harassment 
and safety. 

Electronically stored data is often sought by opposing parties in litigation and 
by criminal justice authorities, since it may be the only record of a conversation or 
transaction. For purposes of evidence both state and federal courts have concluded 
that email records are a special form of computer records and are considered an 
official "record" of the organization. Consequently, email is rapidly becoming a 
critical information source in litigation. Recent court cases have found "smoking 
guns" in old email and early drafts of corporate documents. The early drafts may 
not be binding, but may sometimes be used to establish a party's intent and the mind 
set of the author at the time a message was created. 

Many organizations have no way to manage their email message. Email is a 
record. Most organizations do not have a system to index their email messages with 
other client related documents. Many organization do not have a system to record, 
store and purge email messages in the same manner they manage their traditional 
records and it's creating enormous risks. 

Most organizations have no control over or record of the document sent as 
email file attachments to computer systems and organizations outside their 
organization. Employees often view email as equivalent to a private conversation 
and does not reflect the official position of the organization. These communications 
reflect preliminary thoughts or ideas that have not been reviewed by the organization 
and typically only reflect the personal opinion of the parties involved. Yet, since 
employees of the organization create these communications, court and regulatory 
agencies may conclude these records reflect the organization's view. In addition, 
personal email messages created by employees may not be the type of email 
messages an organization may wish to record and retain in their records management 
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system. Currently, there is no system to separate personal email from business 
email. 

Most organizations have not determined the records retention period and 
procedures for email and established procedures to delete email from backup tapes. 
5 Information system managers generally develop elaborate procedures to backup and 
preserve email records for many years. Some system operators believe that backup 
information should be saved for long periods believing "longer is better." Even with 
short back up cycles, messages may still be maintained due to poor procedures for 
erasing or recycling backup tapes. Even when magnetic tapes have been erased, 

10 overwritten, or damaged, experts using sophisticated techniques may still recover the 
information for litigation. 

The concept of email is still new enough that companies who want to 
establish their own guidelines are pretty much on their own, since no industry 
standard currently exists. 

15 There is a need for an email system to track, sort, index, manage, 

authenticate, purge and store email messages, with other documents, in a database to 
insure that the email messages retained in the database may be the email messages 
an organization chooses to retain as their official records versus unorganized 
messages that may have the potential to create a liability for the organization. 

20 There is a further need for a system that grants the senders and receivers of 

email messages greater control over how their email messages may be sent, 
received, tracked and purged. 

SUMMARY OF THE INVENTION 
25 To overcome the limitations in the prior art described above, and to 

overcome other limitations that will become apparent upon reading and 
understanding the present specification, the present invention discloses a method and 
apparatus for managing electronic records. A system in accordance with the 
principles of the invention performs the steps of creating an electronic tag that 
30 uniquely identifies an electronic record, storing the electronic tag, and distributing 
the electronic record. The method further performs the steps of analyzing a network 
user's workstation specifications, analyzing a network user's user profile, and 
generating a reference code, wherein the electronic tag is generated from information 
analyzed in the network user's workstation specification, the network user's user 
35 profile, and the reference code. 

One preferred embodiment of the present invention includes a system that 
provides for the selective purging of emails. The sender or may determine whether 
an email is purgeable or not purgeable by the recipient. Alternatively, the system 
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may determine the purge characteristics of a particular email based on the 
information stored in the electronic tag. 

These and various other advantages and features of novelty which 
characterize the invention and various preferred embodiments are pointed out with 
particularity in the claims which are annexed hereto and which form a part hereof. 
However, for a better understanding of the invention, its advantages, and the objects 
obtained by its use, reference should be made to the drawings which form a further 
part hereof, and to accompanying descriptive matter, in which there is illustrated and 
described specific examples of apparatus in accordance with preferred embodiments 
of the invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Referring now to the drawings in which like reference numbers represent 
corresponding parts throughout: 

Figure 1 is a block diagram illustrating an electronic record management 
system according to an embodiment of this invention; 

Figures 2A-2C are flow diagrams depicting an email distribution process. 

Figures 3-3C are flow diagrams illustrating the system 140 processing an 
incoming email messages; 

Figure 4 is a block diagram illustrating the steps performed by an electronic 
record management system 100 according to an embodiment of this invention; 

Figure 5 is a flow diagram illustrating the system 140 reading and executing 
an email's reference code; 

Figures 6-6D are flow diagrams illustrating the steps typically performed by 
the email management system 140 in executing a minute mail message; 

Figures 7-7B are flow diagrams illustrating a typical electronic contract 
process performed by the email management system 140; 

Figures 8A-8C are an exemplary screen displays illustrating an electronic 

tag; 

Figure 9 is an exemplary screen display illustrating a business email screen; 
Figure 10 is an exemplary screen display illustrating a the personal email 

screen; 

Figure 1 1 is an exemplary screen display illustrating a minute mail screen; 
Figure 12 is an exemplary screen display illustrating a purge confirmation 
report screen; 

Figure 13 is an exemplary screen display illustrating an intranet-base email 

screen; 
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Figure 14 is an exemplary screen display illustrating a bulletin board email 

screen; 

Figure 15 is an exemplary screen display illustrating an email proposal 

screen; 

Figure 1 6 is an exemplary screen display illustrating an email proposal 
confirmation screen; 

Figure 1 7 is an exemplary screen display illustrating another email proposal 

screen; 

Figure 1 8 is an exemplary screen display illustrating another email proposal 

screen; 

Figure 1 9 is an exemplary screen display illustrating another email proposal 

screen; 

Figure 20 is an exemplary screen display illustrating another email proposal 

screen; 

Figure 21 is an exemplary screen display illustrating email proposal signature 

screen; 

Figure 22 is an exemplary screen display illustrating the email contract 
electronic tag screen; 

Figure 23 is an exemplary screen display illustrating an electronic tag screen; 

Figure 24 is an exemplary screen display illustrating a screen to request an 
email record; 

Figure 25 is an exemplary screen display illustrating a search engine 
interface; 

Figure 26 is an exemplary screen display illustrating another search engine 
interface; 

Figure 27 is an exemplary screen display illustrating an email report; 

Figure 28 is an exemplary screen display illustrating an email records 
retention notice; and 

Figure 29 is an exemplary screen display illustrating a records retention 
confirmation notice. 

DETAILED DESCRIPTION OF THE INVENTION 
In the following description of the exemplary embodiments, reference is 
made to the accompanying drawings that form a part hereof, and in which is shown 
by way of illustration a specific embodiment in which the invention may be 
practiced. It is to be understood that other embodiments may be utilized and that 
structural changes may be made without departing from the scope of the present 
invention. 
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The present invention provides a method and apparatus for maintaining 
policy compliance on a computer network. 

Figure 1 is a block diagram illustrating an electronic record management 
system 100 according to an embodiment of this invention. The hardware generally 
5 implementing an electronic record management system 100 may include computers 
105 having processors and memories 130 distributed over a network as is well- 
known in the art. The memory may include random access memory (RAM) or fixed 
storage. The program steps implementing this invention are stored in the memory 
130 and executed by the computer processor 105. The present invention may be 

10 implemented using an intranet based application that can be stored on central 
servers, waiting to be called up and manipulated via a Web browser from any 
location. Those skilled in the art will recognize that a variety of configurations can 
be used without departing from the scope of the present invention and that a wide 
variety of distributed and multi-processing systems may be used. 

15 A document management system 135 and an email management system 140 

may be included and may feature an electronic tag for maintaining historical records 
for documents within the systems 135 and 140. The document management system 
135 and the email management system 140 may both reside on an Intranet and the 
documents may be in HTTP format. The documents from the systems 135 and 140 

20 both systems may be filed in a central repository database 150. 

The email management system 140 manages email records. An email records 
database 180 may contain a read-only copy of email messages generated from the 
system 140 that may only be accessed by an encryption key. A watermark database 
200 marks and authenticates an email message that has been stored in the email 

25 records management database 180. An electronic contracts database 190 stores and 
records email contracts and their status. An email records retention module of the 
policy compliance monitor 1 10 provides system administrators with a checklist of 
procedures to execute as part of managing the system 140. The policy effectiveness 
module 120 monitors network user email policy compliance. Each of the blocks of 

30 FIG. 1 will be introduced, followed by a detailed explanation of each block. 

Block 110 represents a policy compliance monitor for monitoring 
compliance across the network. 

Block 115 represents a policy compliance and reporting module for 
managing information received from the compliance monitor. 

35 Block 120 represents the policy effectiveness module for managing the 

policy compliance monitor 110. 

Block 130 represents a database or memory for storing policy and 
compliance information. 
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Block 135 represents the document management system of the compliance 
monitor 110. 

Block 140 represents the email management system of the compliance 
monitor 130. 

5 The document management system 135 assigns an electronic tag to all 

documents. The electronic tag is a method to track and index documents in a central 
repository residing on an Intranet web server. The electronic tag also provides a 
method to track documents sent as email file attachments. 

The email management system 140 uses electronic reference codes 

10 embedded in electronic tags to track, index, record, store and purge email messages 
with other client related documentation in a central database. An electronic tag 
provides a method to track and index email messages in a central repository. The 
electronic tag also provides a method to retain an authentic record of all business 
email messages sent and received by the organization. 

1 5 The present invention discloses a method and apparatus for maintaining 

policy compliance on a computer network. FIG. 4 is a block diagram illustrating the 
steps performed by an electronic record management system 100 according to an 
embodiment of this invention. Block 400 represents the system 140 creating an 
electronic tag that uniquely identifies an electronic record. Block 402 represents the 

20 system 140 analyzing a network user's workstation specifications. Block 404 
represents the system 140 analyzing a network user's user profile. Block 406 
represents the system 140 generating a reference code, wherein the electronic tag is 
generated from information analyzed in the network user's workstation 
specification, the network user's user profile, and the reference code. Block 408 

25 represents the system 1 40 storing the electronic tag. Block 410 represents the 
system 140 distributing the electronic record. 

One preferred embodiment of the present invention includes a system that 
provides for management functions related to electronic records, such as the 
selective purging of emails. The sender or may determine whether an email is 

30 purgeable or not purgeable by the recipient. Alternatively, the system may 

determine the purge characteristics of a particular email based on the information 
stored in the electronic tag. 

The policy compliance monitor 110 works with the policy effectiveness 
module 120 to provide network user compliance monitoring with network security 

35 policy stored in a database, it electronically evaluates network security policy 

compliance based on network user compliance, and it undertakes a network policy 
compliance action in response to network security policy compliance. Network user 
compliance monitoring is defined as monitoring network activity to insure users are 
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in compliance with the organization's network security policies. Network security 
policies typically include a set of rules designed to limit an organization's risk and 
liability. 

The policy compliance and reporting module 1 1 5 provides automated policy 
5 monitoring as well as policy violation procedures and reporting. It also tracks policy 
investigations and generates policy investigation reports. These procedures work in 
conjunction with existing policy compliance reporting, discipline and grievance 
procedures to uphold the organization's technology policies. The policy compliance 
and reporting module 1 1 5 monitors and records user and network system activities 
10 audit procedures and reporting, policy violation procedures/investigations/reporting, 
, compliance/non-compliance status reporting. 

The policy effectiveness module 120 electronically collects, records, 
analyzes and stores information from policy compliance monitoring, analyzes policy 
compliance and reporting, evaluates network policy compliance actions undertaken 
15 in response to the network security policy violations and electronically implements a 
different network security policy selected from network security policies stored in a 
policy database. The policy effectiveness module 120 analyzes information 
collected from the policy compliance and reporting module 1 1 5 to determine if 
network user compliance policies are effective. If a policy is determined to be 
20 ineffective, a new policy may need to be implemented. 

A sample policy compliance monitor, policy compliance and reporting 
module, and policy effectiveness module are disclosed in Application Serial No. 
09/104,946, entitled "NETWORK POLICY MANAGEMENT AND 
EFFECTIVENESS SYSTEM," filed on June 25, 1998, by Andrea M. Jacobson, 
25 which application is incorporated by reference herein. 

Email Management System 140 

The electronic record management system 100 may include an email 
management system 140. The email management system 140 may include existing 

30 email systems, such as a Lotus Notes® system. The email management system 140 
may be a web-based application that assigns an electronic tag with a reference 
number to all email messages originating from the organization. Typical email 
messages created in and read by the email management system 140 are HTTP 
standard. Accordingly, such documents may be created and retained in HTML 

35 format and may utilize an HTML interface that may be read by any web browser. 
Alternatively, email documents may be stored on file servers in text formats such as 
those readable by word processing and office suite products. In the preferred 
embodiment, all email messages typically are stored on intranet web servers instead 
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of the file servers in word processing and office suite products. This allows 
sophisticated HTML and JavaScript based email forms and the back end application 
development capabilities of HTTP servers and the World Wide Web. A system 
administrator may configure who can read, edit and access each document or 
5 directory of documents as demonstrated with existing Internet access and security 
protocols. 

In the system 140, email may include text, graphics and audio/video 
communications. The email management system 140 typically provides email 
reference codes, and such email reference codes may include, for example: business 
10 email codes, personal email mail codes, Intranet email messaging, message purging 
codes, minute email codes, limited email codes and a bulletin board for internal, 
broadcast email messages. The functionality of the email management system 140 
may be based on user-definable email reference codes set forth by an organization's 
network policies. 

15 An organization's network policies may define how, what and if email 

messages may be registered with the system 140 at the creation stage or purged by 
the system 140. An electronic tag may be attached to all email message templates. 
An electronic tag is a set of data stored with an email message in the email records 
database 1 80. The electronic tag includes information fields that may provide a 

20 method to centrally index, search, store, monitor and record email messages with 
other documents, track and record email history, monitor policy compliance 
including access to and disclosures of documents sent as email file attachments, and 
may determine the destruction of email documents. Typically, an email header may 
contain fields for a recipient's address, sender's address, subject, copy, and blind 

25 copy. An electronic tag may contain a sender's workstation specifications, including 
but not limited to, the software used to create the email, the version of the software 
used to create the email, workstation serial number, date, time and workstation 
model number. The electronic tag may include network user information obtained 
from the network user's User Profile. Network user information may include, but 

30 not limited to, employee identification number, network access code, 

department/division information, title, password, login verification, workstation 
specs and mailstop. Figures 8A, 8B and 8C are exemplary screen displays 
illustrating the electronic tag according to one embodiment of the invention. 

For example, an organization may require a network user to have approval 

35 from upper management in order to purge email messages. Another optional policy 
is to require all internal email messages be to be purged daily, so that no internal 
record is maintained. Another policy may be to monitor personal email message to 
insure that network users are not conducting business for personal gain. Therefore, 
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the functionality of the system may be based on user-definable email reference codes 
set forth by an organization's network policies. 

Email policy options may be integrated into the policy compliance monitor 
110 and the document management system 135 so that all email messages, 
5 originating from within the organization can be indexed, recorded, retrieved, tracked 
and purged in the central repository database of the document management system 
135. Further, all email messages may be assigned an electronic tag which may be 
copied to, recorded and retrieved from intranet web servers of the document 
management system 135 and may be measured for policy compliance by the policy 
10 compliance monitor 130. 

Email Reference Codes 

An email message may be assigned an electronic tag. An electronic tag 
typically contains several information fields that collect and track an email's history, 

1 5 including, but not limited to, tracking the number of copies and revisions, who made 
a copy and when, and may contain a reference code. The email reference code may 
be comprised of text letters (i.e., text value) and a numeric value. The text value 
may tell the system how to process the email message. The numeric value may be 
used to identify and track the email to the master file. The numeric value may 

20 correlate the email to a master file stored in the central repository. If a network user 
chooses the minute mail option, a function that allows senders and receivers of email 
messages to send, receive or purge emails from the system 140 without a record of 
the message being retained by the sender, receiver or the log file of the email system 
140, the numeric number may be the network user's employee identification number 

25 paired with a text code, e.g., MMM. Email reference codes are also used to tell the 
system how to process email, and as a method to track and identify the email within 
the system. Email reference codes may be used to process email contracts, personal 
email, business email, bulletin board email, intranet email, identify and track 
incoming email, store and retrieve email messages via search engines from the 

30 central repository database and/or the email records database. 

A reference code may be comprised of text letters (i.e., text value) and a 
numeric value. The numeric value may be used to identify and track the email to the 
master file. The text value may trigger an object and tell it how to process the email 
message. An object has specific characteristics and may carry out specific actions 

35 that are triggered by an event and is stored in the email management database 1 90. 
In email management system 140, the object is a self-contained unit of functionality 
whose specific actions are triggered when a text value matches an email reference 
code. Once the object and the text code are matched, the text code triggers the 
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object to receive instructions from a script language. Every object typically has 
attached to it a script that contains the procedures used to manipulate the object. 
Therefore, the type of email reference code entered into the reference code field 
determines the object that will be used. 

The type of email reference code may also determine the purge options for an 
email message. The sender typically may define an email message as purgeable or 
not purgeable by the recipient. Alternatively, the type of email reference code may 
determine whether an email message is purgeable. 

Figure 5 is a flow diagram illustrating the system 140 reading and executing 
an email's reference code. Typically, a network user may choose the type of email 
message he desires to send from the email message menu in the email application. 
Block 501 represents the system 140 presenting the user with email options. The 
type of email message the network user chooses is represented by a text value that 
may appear in the reference code of the email's electronic code. Block 502 
represents the system 140 reading the text values of the user's email choice. A 
numeric value is also paired with the text value to create the reference code for the 
email. Block 503 represents the system 140 reading the numeric value of the user's 
email choice. 

A sorting algorithm may be responsible for reviewing text values and 
matching it to an object. Block 504 represents the system 140 analyzing text code 
and object codes. The text value may determine the functions the object will 
execute. The system 140 analyzes the text value in relation to the objects in the 
email management database 190. If the text values are equal, the system 140 
chooses the object and begins reading the object's scripting language. 

Block 505 represents the system 140 matching the text code to an object. 
The scripting language contains the procedures for handling the email message. 
Block 506 represents the system 140 reading an object's script. 

For example, an organization may determine that the letters MMM and a 
master file number may be used as the email reference code for minute mail. When 
the network user having an employee number of 1030 decides to send an email, he 
may enter the code MMM 1030 into the email reference code field in the electronic 
tag of an email message. When the network user sends the email message, the 
system 140 may read the email's electronic tag may begin executing the scripting 
code within the application. Each scripting code typically correlates to an email 
reference code and activates an object. 

The system 140 may read the email's electronic tag, the network user's user 
profile and the identity of the network user's workstation (e.g., the Win95 registry). 
The email management system 140 may read the workstation's local machine which 
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may include fields depicting settings specific to the machine and settings specific to 
the network user from the workstation's operating system. Machine settings may 
include the hardware profile, including serial number, system specifications, 
software, including licensed software, non licensed software (i.e., personal software 
installed by the network user), software drivers, memory status, system diagnostics, 
and other information. Network user information may include the network systems 
logon status, access status (e.g. remote access or local), network status, software 
configurations, and other user definable information fields. 

Next, the system 140 may read several fields from the network user's user 
profile, including the network user's name, network user's email address, network 
user's surface mail address, employment status (i.e. temp, contract, virtual), title, 
department, organizational chart indicating who the network user reports to, the 
direct reports, his assistant, mail station address, and employee identification 
number. System 140 may also read system information, which may include 
hardware information including, but not limited to, serial number, system 
specifications, software including licensed software, non licensed software (i.e., 
personal software installed by the network user), software drivers, memory status, 
system diagnostics, software information included but not limited to software 
configurations, licensed software, non licensed software, logon status, network 
user's system access, security status, and any special network access or privileges 
(i.e. using network for charitable uses.), system compliance status and other user 
definable information fields. 

Next, the system 140 may read the email reference code and determine that 
the email is a minute mail, e.g. text value of MMM. The MMM may trigger an 
object to carry out its specific actions. In this case, the system 140 may send the 
email message to the recipient. The object may apply font and color changes to the 
email. After the recipient has opened and received the email message, the system 
140 may allow the network user to view the email message for a minute, or other 
period of time. After the time has elapsed, the message may disappear from the 
screen and the system 140 may begin to purge the email message from the network 
user's email application, the sender's email application and the email log file. The 
system 140 may read the sender's email address field, recipient's email address 
field, subject field, time and date field, and copy fields of an email's electronic tag. 
Next, the system 140 may read the email server log file. The system 140 may use a 
sorting algorithm to search for the email header fields to match the sender's email 
address field, recipient's email address field, subject field, time and date field, and 
copy fields of an email's electronic tag. Once the exact email entry is found, the 
system 140 may purge the email message by deleting the entry from the system 140. 
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Next, the system 1 40 may read any back up tapes, other storage media or any copies 
of the email that may have been listed in the copy field of the email or forwarded to 
other recipients. The system 140 may use a sorting algorithm to search for the email 
header fields to match the sender's email address field, recipient's email address 
5 field, subject field, time and date field, and copy fields of an email's electronic tag. 
Once the exact email entry is found, the object may purge the email message from 
the system 140 by deleting the entry from the system. The system 140 records the 
purging process in the email management database 190. The system 140 sends a 
final message to the sender and the recipient to indicate the purging process is 
10 completed. 

Business Email Reference Code 

Email is a record that an organization may need to retain as a record. A 
business email is defined as an email message that an organization may want to retain 
15 because it is a record of the organization's business. This may include email 

messages representing client correspondence, transactions or other emails containing 
valuable information the organization desires, or is required to retain as a record. 

The email management system 140 assigns an electronic tag with an email 
reference code to all business email messages to assist in index, record, store, search, 
20 retrieve and dispose of the email records. 

Figures 2A through 2C are flow diagrams depicting an email distribution 
process. In an exemplary embodiment, the email message may be a business email 
message. Block 201 represents the system 140 receiving a request from the network 
user to compose a business email message. Figure 9 is a screen display illustrating a 
25 typical business email screen. The network user selects an email page to identify the 
type of email message the user may compose. Email pages may include business 
email, personal email, Intramail and bulletin board mail. 

The email management system 140 reads the network user's workstation 
specifications. Block 202 represents the system 140 reading the network user's 
30 workstation and network address. For example, when utilizing a Microsoft 

Windows operating system, the document management system 140 may read the 
network user's operating system registry, which may be a tree-structure, hierarchical 
database where the system and programs store data. The registry may be stored in 
two files. The actual files used can vary based upon configurations of the system but 
35 will generally be split into a file having settings specific to the machine, (typically 
system.dat) and a file having settings specific to the user (typically user.dat.) from 
the workstation's operating system. 
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The email management system 140 reads the a workstation's local machine 
which may include fields depicting settings specific to the machine and setting 
specific to the network user from the workstation's operating system. Machine 
settings may include hardware profile including serial number, system 
specifications, software including licensed software, non licensed software (i.e., 
personal software installed by the network user), software drivers, memory status, 
system diagnostics, and other information. Network user information may include 
the network systems logon status, access status (e.g. remote access or local), network 
status, software configurations, and other user definable information fields. 

The system 140 may read fields from the network user's user profile. Block 
203 represents the system 140 reading a network user's user profile. 

An organization may use an indexing system to identify work tasks. For 
example, the organization may track information on a client or project basis. All 
clients or projects in the email management system 140 may be assigned a reference 
code, and a master file number may be assigned to all project, entity, and/or business 
files listed in the document management system 140. In the preferred embodiment, 
a new master file is created and entered into the system 140 in a manner similar to 
that used by Microsoft products, e.g., the creation of a New folder or file. In the 
system 140, when a master file is established it is typically replicated in the email 
records database. In the preferred embodiment, a master file is replicated in a 
manner similar to that of replicating a database in the Lotus Notes® system. 

After the user has composed an email and has clicked on the send icon in an 
email application, the system 140 typically presents the user with a menu listing files 
in the central repository database. The user may select the file in the central 
repository database in which to store a copy of the email message. After the user has 
chosen the location to store the email message in the central repository, the system 
140 typically reads the master file number field from the file in the central 
repository. The master file number and the email Intranet web site may be used to 
generate a reference code for the business email. If the email message is a business 
email, the system may assign the letters BEM to the beginning of the reference code. 
Block 204 represents the system 140 generating the reference code. 

For example, if a user has composed a business email message, he may 
choose to index and store the business email. The user may indicate the file where 
the email messages is to be stored. The system 140 may read the master file number 
from the location where the network user wishes to store the business email 
message. Next, the system 140 may read the Intranet site to determine the type of 
email message the user has composed. Therefore, if a master file code is 1000 and 
the system 140 determines that the network user composed an email message from 
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the business email Intranet site, the reference code for the business email electronic 
tag may be BEM1000. This reference number may be used by the system 140 to 
index and track the email in the system 140. In addition, the email management 
system 140 may use the business email reference code to index, record, search, 
retrieve and store all business email correspondence with other client, project and/or 
business records and determines business email storage and disposal. The reference 
code may be recorded in the reference code field of the electronic tag of the email 
message. Block 205 represents the system 140 generating an electronic tag. 

In a preferred embodiment, after the business email message has been 
indexed, the system 140 sends the original email message and generates two copies 
of the business email message. Typically, all business emails are stored in read-only 
format in the central repository database 150 and in the email records database 180. 

Figure 2B is a continuation of the email recording process depicted in Figure 
2A. Block 206 represents the system 140 sending the original email message. 
Typically, the two copies are converted into HTTP format. Block 207 represents the 
system 140 copying the email message and its electronic tag. The process is similar 
to that of word processing programs convert word processing documents into HTTP 
format by automatically attaching HTML tags to the document, as is known in the 
art. 

Figure 2C is a continuation of Fig. 2B. Block 208 illustrates the system 140 
distributing the copied email messages to databases 150 and 1 80. Block 209 
represents the system 140 sending the email to the recipient of the email. Block 210 
represents the system 140 converting the email messages to HTTP format. Block 
211 represents the system storing the email messages in the central repository 
database 150. Block 212 represent the system 140 storing the email in the email 
records database 180. 

Personal Email Codes 

Personal email codes allow an organization to enforce a policy regarding 
personal email use. The email management system 140 may give the organization 
the opportunity to monitor email policy compliance by setting maximum email 
message usage levels for personal emails. 

A network user may be assigned a personal email code number. Figure 10 is 
an exemplary screen display illustrating a personal email screen. Personal email 
codes may end in a text, e.g., PEM, that indicates a personal email message and 
includes the network user's employee identification number. For example, a 
network user's employee identification number may be 14772, and the user's 
personal email code number may be PEM14772. 
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A network user may send a personal email message from a personal email 
Intranet site. The network user may enter his personal email number into the 
reference code field of the electronic tag of an email message. The email 
management system 140 may be configured to read the personal email code and 
5 compare the personal email code to the maximum number of personal email 
messages assigned to the network user to monitor the number of daily personal 
email messages a network user sends per day. The maximum number may be listed 
in the network user's user profile. 

When composing a personal email message, the user may be required to 

1 0 enter his personal email code into the reference field of the personal email message. 
After the user has composed the email and has indicated that he wants to send the 
email message. The system typically reads the maximum personal email number 
from the network user's user profile and reads the personal email field for email 
messages sent for the day. If the network user is within his personal email range, the 

1 5 email message will be sent to the recipient. If the numbers of email messages are 
greater than the amount of maximum email messages that a user is allowed to send, 
the system will retain the email message in a queue. Those skilled in the art will 
recognize that this "holding" process may implemented when a faulty network 
connection prevents delivery of an email message. Email messages may be retained 

20 in a queue until the network connection can be reestablished. The system could send 
the email message when the user logs into the system on the following day. 
Alternatively, violation of the limits may result in actions other than placing the 
email message in a queue, such as sending the network user or network 
administrator a warning message. The message may also be processed regularly, but 

25 the network email policy violation may be indicated in a log file. 

The personal email code may also signal the system 140 to attach a 
disclaimer to the bottom of the each email message with a PEM as the email code in 
the reference code field. For example, a disclaimer may include a message to the 
receiver that the email message they have received is the opinion of the user and not 

30 that of the employer, thereby limiting the organization's liability. If the network 
user exceeds the maximum personal message limit, the email management system 
140 signals the policy compliance monitor 130 to provide network user compliance 
monitoring with network security policy stored in a database, to electronically 
evaluate network security policy compliance based on network user compliance, and 

35 undertake a network policy compliance action in response to network security policy 
compliance. 
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Minute Mail 

The minute mail function of the email management system 140 allows 
senders and receivers of email messages to purge emails from the system 140 
without any record of the message being retained by the sender, receiver or the log 
5 file of the email system 140. Figure 1 1 is an exemplary screen display illustrating a 
minute mail screen. The system 140 is flexible in that it can perform various user 
definable minute message options including sender purge and recipient purge. 
Typically, the system 140 may also provide several message notification options that 
are similar to Caller-ID options currently sold by phone companies. A network user 

10 may choose minute mail options from a menu of email messaging options within the 
email management system 140. 

Examples of message notification options include block minute mail, 
sender's request to send minute mail, view sender's address prior to opening and/or 
accepting a message, autoreply to decline purge minute mail, autoreply indicating 

1 5 network user accepts minute mail and declines purge, autoreply indicating network 
user accepts and saves all minute mail, minute mail waiting, and purge minute mail 
request denied. 

Each email message typically has an electronic tag. The system 140 may 
record the sender and recipient's message activities in the email's electronic tag. For 

20 example, the system may send notification messages to the sender regarding the 

recipient's treatment of an email message. Several sender reply options may include 
block minute mail, purge unopened minute mail, purge minute mail received, notify 
recipient minute mail request, notify sender decline minute mail acceptance, purge 
minute mail sent confirmation, purged minute mail destroyed confirmation notice, 

25 and purge email and electronic tag. Several purge options that may include purge 
email content only, purge email only, purge file attachment only, purge email and 
retain file attachment, and purge email and electronic tag. The network user may 
define his minute mail preferences in the email application by indicating his minute 
mail preferences. This is similar to current email applications in which the network 

30 user may indicate how he wants to be notified of any incoming email message. 

System administrators may also define minute mail preferences for the organization. 
Once again, this is typically a user-definable feature. 

The system 140 may read the purge rights field of the user profile to 
determine the purge rights and/or options of the network user. A purge code listed 

35 in the purge rights field may be stored in the email management database 1 80. The 
purge code values may coordinate with the purge rights and purge options granted to 
the user in the system. The network user's purge rights may be recorded in the 
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network users user's profile. Figure 12 is an exemplary screen display illustrating 
purge confirmation report; 

The sender and the recipients of a message may have the option of overriding 
a minute mail purge request. For example, a network user may send a minute mail 
5 to be automatically purged by the system. The recipient of this message may choose 
to save the minute message instead of allowing the system to continue executing the 
sender's choice of purging the minute mail message. This is typically another user- 
definable feature. An organization using the present system may select who has 
access to the purge options in accordance with their network policies. The system 

1 0 administrator may determine who has purge minute mail rights. Network users may 
be assigned a purge code. The codes may be stored in a network user's user profile. 
For example, an officer of an organization may have more purge rights and/or 
options than temporary employees in an organization. 

With the minute message option, an email message may remain on the screen 

1 5 for a limited period of time after the user has opened the email message. The 
network user or the system administrator may determine the period of time a 
message is displayed. In the present system, the network users typically have the 
option to accept, decline, block, purge, print, copy or retain the message. 

Figures 6A - 6D are flow diagrams illustrating the steps typically performed 

20 by the email management system 140 in executing a minute mail message. Block 
600 represents the system 140 receiving a request from a network user for an email 
r form. The network user may choose the type of email message he or she chooses to 
send. The network user may also fill in the fields of the electronic tag. For example, 
an organization may determine that the letters MMM and the employee's 

25 identification number are to be used as the email reference code for minute mail and 
the network user's employee identification number may be 100. The code 
MMM100 may be entered into the email reference code field. Block 601 represents 
the system 140 presenting an email form to the network user. The network user 
creates the email message and indicates that the message is to be sent. Block 602 

30 representing the system 140 receiving the email form. When the network user sends 
the email message, the system may read the email's electronic tag to begin executing 
the scripting code within the email management system 140. Block 603 represents 
the system 140 reading the electronic tag. Each scripting code correlates to an email 
reference code. Block 604 represents that system 140 reading the reference code. 

35 The scripting code activates an object. 

The system 140 may read the email's electronic tag, the network user's user 
profile and the network user's workstation specifications including, but not limited 
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to the workstation hardware configuration, hardware descriptions, BIOS info, 
software configuration, and network information. 

Block 605 represents the system 140 reading the numeric values of the 
reference code. Block 606 represents the system 140 reading the user's profile. 
Block 607 represents the system 140 reading the network user's workstation. 

The system 140 may read the reference code MMM and determine that the 
email is a minute mail. 

Block 608 represents the system 140 analyzing text values of the reference 
code. The reference code, e.g., MMM, may trigger an object to carry out specific 
actions. 

Block 609 represents the system correlates the text code to an object. The 
system 140 may send the email message to the recipient Block 610 represents the 
system 140 matching a text code to an object 

Block 611 represents the system 140 reading the object's script. 

Block 612 represents the system 140 sending the email message. The object 
may apply font and color changes to the email. 

Block 613 represents the system 140 reading and applying the format 
options. The email management system 140 supports HTTP format, therefore 
several email message format options may include a variety of font style, font colors 
and email message designs. 

Block 614 represents the system 140 selectively activating a message status 
indicator. After the recipient has opened and received the email message, the system 
140 may allow the network user to view the email message for a limited period of 
time. 

Block 615 represents the system 140 recording the recipient's opening the 
email message's electronic tag. After a specified period of time has elapsed, the 
message may disappear from the screen and the system 140 may begin to purge the 
email message from the network user's email application, the sender's email 
application and the email log file. 

Block 616 represents the system timing the email message. The system 140 
may read the sender's email address field, recipient's email address field, subject 
field, time and date field, and copy fields of an email's electronic tag. 

Block 617 represents the system 140 deleting email from the user s screen. 

Block 618 represents the system 140 reading the sender's email address field. 

Block 619 represents the system 140 reading the recipient's email address 

field. 

Block 620 represents the system 140 reading the subject field. 
Block 621 represents the system 140 reading the date and time field. 
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Block 622 represents the system 140 reading the copy field. 

Figure 6D is a continuation of the flow diagram of Figure 6C. Block 625 
represents the system 140 reading an email server log file. The system 140 may use 
a sorting algorithm, as is known in the art, to search for the email header fields to 
match the sender's email address field, recipient's email address field, subject field, 
time and date field, and copy fields of an email's electronic tag. 

Block 626 represents the system 140 sorting log files to match address fields 
of the email message. A typical email address fields may include to, from, subject, 
cc:, and bcc:. Once the exact email entry is found, the system 140 may purge the 
email message by deleting the entry from the system. 

Block 627 represents the system 140 purging the email message. 

The system 140 typically provides user-definable features that allow users to 
interrupt the purging process. The system 140 may be configured to present the 
network user with an icon or message box that permits the network user to 
selectively interrupt the message purging process. The system may also be 
configured to not allow interruption, whereby once the system 140 enters the log file 
deleting routine the network user may not be able to interrupt the purge process. 

Email systems known in the art record in the email server logs the sender and 
the recipient of the email message. Generally, the message content is not recorded. 
In the preferred embodiment of the present system, the email system 140 has tape, or 
other storage media, backup policies, and procedures that differ from the traditional 
computer network backup and storage policies and procedures. Those skilled in the 
art will recognize that any hardware/software configuration is possible that allows 
the email system 140 to control the backup and storage procedure, thus allowing the 
effective purging of emails in the system 140. Generally, longer backup cycles for a 
network are preferred by system administrators since it may ensure an organization's 
ability to recover from computer or network failures or disturbances. For an email 
system, generally, shorter backup cycles are preferred to ensure no unwanted copies 
of email messages reside in the system or on back up media. 

In the system 140, no backup of the email system 140 may be the optimal 
backup procedure to ensure that no unwanted copies of email messages reside in the 
system or on back up media. Backup procedures may be necessary for all of the 
email databases within the system 140. This may include, but is not limited to, the 
email records database 180 and the email management database 190. 

System 140 may be configured so that copies of email that may have been 
listed in the copy fields of the email header or messages forwarded to other 
recipients are searched by the system. Block 628 represents the system 140 reading 
the copy and forward fields of the email header. The system 140 may use a sorting 
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algorithm, as is known in the art, to search for the email header fields to match the 
sender's email address field, recipient's email address field, subject field, time and 
date field, and copy fields of an email's electronic tag. Once the exact email entry is 
found, the object that is correlated to the purge code in an email's electronic tag may 
5 purge the email message from the system 140 by deleting the entry from the system 
140. 

Block 629 represents the system 140 recording the email purge. The system 
140 may send a purge confirmation message to the sender and the recipient to 
indicate the purging process is completed. Block 630 represents the system 140 

10 sending an email purge confirmation notice. 

The system 140 typically has several user-defined purged message recording 
options. For example, the network user may define if the system 140 is to retain the 
electronic tag from a purged message in the email management database. 
Alternatively, the system 140 may read the purge rights value of the user profile to 

1 5 determine the purge rights and/or options of the network user as defined by the 
policies of the organization or a system administrator. 

The system 140 may be configured so that the system administrator may 
determine who has purge message recording rights. Network users may be assigned 
a purge code. A purge code is typically configured in system 140 to tell the system 

20 how to process an email. If a network user has a purge code in their user profile, the 
system may permit the network user to purge any email messages he chooses. 
Alternatively, the purge code may allow a user to purge only the content of an email 
(retaining the electronic tag) or both the email and the electronic tag. The purge 
codes may be stored in a network user's user profile, and it may tell the system that 

25 the network user has the right to purge email messages. For example, a chief 
executive officer (CEO) may have more purge rights and/or options than other 
employees. The purge value code listed in the purge rights field may be stored in an 
email records database 180. The purge code values may coordinate with the purge 
rights and purge options granted to the user and stored in the network user's user 

30 profile in the system. 

After an email message has been disposed, the system 140 may record the 
disposal in the message disposal status field of an email's electronic tag. 

An Internal, Intranet-Based Mailing System 

35 An internal, intranet-based mailing Intranet site may provide fast inter-office 

messaging. Email may be used for more formalized correspondence and record 
keeping. Figure 13 is a screen display illustrating an intranet-base email screen. 
Internal messages can be sent to individuals and small groups. The internal 
messages can be customized and may be limited in length, for example, to 200 
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characters per message. System 140 may be configured so that internal messages do 
not have a tracking or reference number and may be purged daily or weekly from the 
system. Such internal messages could include prefabricated messages. Since 
internal messages may not have a tracking or reference number in such a system, the 
messages may not be tracked or indexed by the system. QuickNotes™ is an existing 
Intranet-based email system that provides inter-office messaging. 

Bulletin Board Email Postings 

A bulletin board, Intranet mailing system may provide opportunities for 
employees to post messages and other internal notices. Figure 14 is a screen display 
illustrating a bulletin board email screen according to an embodiment of the 
invention. If messages are posted to a bulletin board, email may be used for more 
formalized correspondence and record keeping. 

File Encryption Tracking, and Monitoring 

File encryption tracking and monitoring may protect data confidentiality and 
reduce its accessibility. The system 140 may also be configured so that it uses file 
encryption tracking and monitoring to help reduce the risk of data loss by accidental 
or intentional modification, the disclosure of or destruction of confidential or 
proprietary information, or through the unauthorized use of information for 
commercial gain or malicious purposes. The file encryption tracking and monitoring 
activity may be reported to the policy compliance monitors 130 for compliance 
reporting and tracking. Known products configured to accomplish these tasks 
include the InvisiMail™ system available from RPK. 

Writing Standards and Email Content Policy Compliance 

The system may be configured to include a writing standards policy 
compliance function in order to enact a more careful review of email messages sent 
outside of the organization and prevents problematic email from ever being created. 
Known products that are configured to accomplish this functionality include Privacy 
Alert software available from Aladdin Web Solutions. 

User Identity Module 

To be in policy compliance, users typically must adhere to the addressing 
and naming conventions as defined by their organization. A user identity module in 
the present system may be configured to ensure that a network user is not allowed to 
send email messages using an alias or a false identity. Generally, a network user is 
assigned one email address, and if the network user attempts to send an email 
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message under a false email address or name, the system will not allow the email 
message to be sent. The Novell Groupwise system available from Novell is an email 
product that restricts network users from sending an email message by using an alias 
or false email address. 

5 

Email Storage Monitoring 

The system 140 may be configured to monitor email storage space and to 
make the storage space size user-defined. For example, a CEO may be permitted 
greater email storage space and bandwidth than other employees. The system 140 

10 may also be configured to read the job level fields of the user profile to determine 
the amount of email storage space and bandwidth to allocate to the network user. 
The job levels listed in the job level field may be stored in the email records 
management database 1 80. The job level values typically coordinate the amount of 
storage space the system 140 may allocate for email storage. 

1 5 For example, a CEO may have a job level A and an administrative assistant 

may have a job level W. When the CEO logs into the system 140, the system 140 
may read the job level field from the CEO's user profile. Next, the system 140 may 
refer to the email storage database 1000 to match the value listed in the job level 
field to the email storage allocation field. In this example, job level A may be 

20 allocated 500 kilobytes of memory. The system 140 allocates the appropriate email 
storage space for the CEO. Likewise, when the administrative assistant with job 
level W logs into the system 140, the system 140 may read the job level field from 
the administrative assistant's user profile. Next, the system 140 may refer to the 
email storage database 1000 to match the job level field to the email storage 

25 allocation field. In this example, job level W may be allocated 100 kilobytes of 
memory. 



Passwords 

The email compliance system 140 has time and date fields to send email to 
30 users who have not changed their passwords for a set period of time. The email 
management system 140 may be configured to require network users to choose 
better, hard-to-break passwords. The email management system 140 preferably 
tracks a network user's log-in/passwords/hardware token information and monitors 
password access to the system 140. 

35 

Message Status 

The system 140 may alert the network user to the status and arrival of an 
email message. When a network user receives an email message, the system 140 
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may read an email's reference codes to determine how to process the email message. 
Each email reference code typically matches an object stored in the email 
management database. Each object may have a script (i.e., scripting language) that 
instructs the object how to process the email message. The scripting language of an 
5 object may contain instructions related to the distribution, routing, font styles, 

access, viewing, purging and message status of an email message as indicated by the 
email's reference code. 

Each email reference code may trigger an icon in the system 140. The icon 
may alert the user when an email message has been received. All message icons and 

10 status features typically are user-definable functions. An email message's font style 
and color may differ from other email message types. An application the network 
user is running may blink or flash to alert the user of an incoming email message. 
For example, a minute message may have a bright blue font, and a distinctive chime 
may be assigned to the minute message. Another function may include utilizing the 

15 clock menu bar, as in Microsoft Windows applications. The clock menu bar may 
pulse, flash or change color to indicate to the network user a received a minute 
message. Distinctive chimes or announcement options may be activated to alert the 
receiver that an email message has arrived. The ring options include ring, ring and 
vibrate, flash, beep once, silent and vibrate. Various announcement options may be 

20 including a male voice, female voice, child's voice or other sounds. 

Message Viewing 

System 140 may be configured so that a network user may define who can 
access and view an email message by choosing options from the message viewing 

25 field in an email's electronic tag. In such a system, network users may chose an 
option to block the viewing and access to the text of an email message. Known 
software with text blocking features includes Page Vault software available from 
Authentica Security Technologies, Inc. Typically, system 140 is configured so that 
the text blocked email may be saved, printed, forwarded, copied and/or may be sent 

30 as a minute mail, and so that all revisions, copies and purges of an email may be 
recorded by an email's electronic tag. 

Another typical email viewing option may prevent an email from being 
viewed outside of the organization. The system may use an email reference code 
that reads the network user's workstation specifications. Prior to sending a new or 

35 previously stored email message, the system may read the network user's 

workstation specifications, including but not limited to network connections, modem 
utilization, and/or the registry, and compare the specifications to the user's 
workstation specifications listed in the network user's user profile. If the 

23 



BNSDOCID: <WO 002393 1A2J_> 



WO 00/23931 PCT/US99/24549 

workstation specifications differ from the workstation specifications listed in the 
user's profile, the system typically will not make the email message available for 
viewing. 

5 Incoming Mail 

After the network user has received, opened and read an email message for 
the first time, the system 140 may assign a temporary electronic tag to the email 
message. Figures 3-3C are flow diagrams illustrating the system 140 processing an 
incoming email message. Block 340 represents the system 140 assigning a 
10 temporary electronic tag. The network user may choose to file the email with the 
system 140 or to purge the email. Regardless of the network user's choice, the 
system 140 may require all email messages to have an electronic tag. This is to 
ensure all incoming and outgoing email is recorded, retained and properly stored in 
the system 140. 

15 The system 140 may be configured to assign a temporary electronic tag to 

the incoming email and hold it in a temporary file in the central repository database 
150. The reference code for the temporary email, e.g., TMP, may be comprised of 
the text values, and the numeric value assigned may be the recipient's employment 
identification number. Block 341 represents the system 140 reading the recipient's 

20 user profile. For example, a temporary electronic tag may have a reference number 
of TMP2121, with 2121 representing the employee's identification number. 

In addition, the system 140 may read the email header information to record 
the recipient's email address, sender's email address, date, time and subject fields for 
the electronic tag. Block 342 represents the system 140 reading the email header 

25 fields. 

The recipient of the email may be reminded that he has an email that is to be 
filed during system logins. Block 343 represents the system 140 sending an email 
reminder. 

Block 344 represents the system 140 asks the network user to determine if he 
30 chooses to save the email in the central repository database 150. 

If the network user ignores the reminders after a predetermined number of 
consecutive logins, for example, after three consecutive logins, the system 140 may 
send a copy of the email to the system administrator who may file the email or may - 
take an action against the recipient. Block 345 represents the system 140 sending 
35 the system administrator a copy of the email. 

A network user normally may choose to save the email message or to purge 
the email message. Figure 6 is a screen display illustrating an email menu screen. 
The network user may fill in the fields of the electronic tag and choose to save the 
email message. If the user indicates that he wants to save the message, the system 
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140 may present the user with a central repository database 1 50 menu. Block 346 
represents the system 140 presenting the network user with the central repository 
database 1 50 menu. The user may indicate the location and name of the file in 
which to store the email message. After the user has chosen the location to store the 
5 email message in the central repository, the system may prompt the network user to 
indicate the type of email message he has received. Block 347 represents the system 
140 prompting the user to indicate the type of email message he has received. 

If the email is a business email, the system 140 may assign a code, e.g., 
BEM, to the beginning of the email with the master file number to create the 

10 reference code for the email. Block 348 represents the system 140 reading the email 
type. If the email is a personal email, the system 140 may assign a code, e.g., BEM, 
to the beginning of the email with the master file number to create the reference code 
for the email. Block 349 represents the system 140 reading the master file location. 
Block 350 represents the system 140 assigning a reference code. The reference code 

1 5 is recorded in the reference code field of the electronic tag of the email message. 
Block 351 represents the system 140 recording the reference code field in the 
electronic tag. 

For example, if a user has received a business email message, he may choose 
to index and store the business email. The user may indicate the file where the email 

20 message may be stored. The system 140 may read the master file number from the 
location where the network user wishes to store the business email message. Next, 
the network user may determine the type of email message the user has composed. 
Therefore, if a master file code is 9082, and the network user indicates that the email 
message is a business email, the electronic tag may be assigned the reference code 

25 BEM9082. This reference number may be used by the system to index and track the 
email in the system 140. In addition, the email management system 140 may use the 
business email reference code to index, record, search, retrieve and store all business 
email correspondence with other clients, projects and/or business records and it may 
determine business email storage and disposal. The reference code is recorded in the 

30 reference code field of the electronic tag of the email message. If the network user 
indicates the email message is a business email (e.g., code BEM) or file, the system 
140 may automatically copy the email message into the email records database 180. 
In addition, the system 140 may read the network user's workstation specifications 
and the network user's user profile to complete the electronic tag. Block 352 

35 represents the system 140 reading the network user's workstation specifications. 
Block 353 represents the system 140 reading the network user's user profile. The 
electronic tag and the email are saved in the email records database 180. Block 354 
represents the system 140 saving the electronic tag and the email. 
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If the network user chooses to purge the incoming email message, the system 
140 may prompt the network user to file the email in the central repository 150. If 
the network user indicates he does not want to file the email message, the system 
140 may read the information from the temporary electronic tag and record it as the 
5 permanent electronic tag for the email. Block 345 A represents the system 140 
sorting files to match fields of the email headers. Block 346 represents the system 
140 reading the temporary electronic tag. Block 347 represents the system 140 
recording temporary electronic tag as a permanent electronic tag. 

The electronic code may be comprised of a text value and the recipient's 
1 0 employee identification number from the network user's user profile. The system 
may assign a text value, e.g., PUR, to the reference code for the soon-to-be-purged 
email. Block 348 represents the system 140 assigning the PUR code to soon-to-be 
purged email. 

Block 349 represents the system 140 reading the user's profile. The system 
15 140 may begin to purge the email message from the network user's email 
application, the sender's email application and the email log file. 

The system 140 may read the sender's email address field, recipient's email 
address field, subject field, time and date field, and copy fields of an email's 
electronic tag. Block 350 represents the system 140 reading the sender's email 
20 address field. 

Block 351 represents the system reading the recipient's email address field. 

Block 352 represents the system 140 reading the subject, time and date fields 
of the email. 

Block 353 represents the system 140 reading the copy fields of the email 

25 header. 

Block 354 represents the system 140 reading the email log file. 

Next, the system 140 may read the email server log file. The system 140 
may use a sorting algorithm as is known in the art to search for the email header 
fields in the log file to match the sender's email address field, recipient's email 
30 address field, subject field, time and date field, and copy fields of an email's 

electronic tag. Block 355 represents the system 140 sorting files to match fields of 
the email headers. 

Once the exact email entry is found, the system 140 may purge the email 
message by deleting the entry from the system 140. Block 356 represents the system 
35 140 matching an email header to fields in the electronic tags. Block 357 represents 
the system 140 purging email. 

Next, the system 140 may read any back up tapes, other storage media or any 
copies of the email that may have been listed in the copy field of the email or 
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forwarded to other recipients. Block 358 represents the system 140 reading the copy 
and forward fields of the email header. The system 140 may use a sorting algorithm 
to search for the email header fields to match the sender's email address field, 
recipient's email address field, subject field, time and date field, and copy fields of 
an email's electronic tag. The system may record the purged email by filing the 
electronic tag in the email management database 180. Block 359 represents the 
system 140 recording the email purge. The purging process is also recorded in the 
email management database 180. 

The system may send a final message to the sender and the recipient to 
indicate the purging process is completed. Block 360 represents the system 140 
sending an email purge confirmation notice. 

Email Contracts 

Electronic communications are influencing contract law. The greatest 
challenge has been to determine exactly when and if a contract is created. In this 
system 140, an organization must determine their electronic contract policies and 
procedures. The email contract policies may determine how electronic contracts are 
recorded, delivered and accepted. 

Figure 7 is a flow diagram illustrating a typical electronic contract process 
performed by the email management system 140. The network user may indicate 
that he desires to begin the electronic contract process by choosing an email contract 
command in the system 170. Block 700 represents the system 140 receiving a 
request for an electronic proposal. In response to this request, the system 140 
provides the network user with an electronic contract template having an electronic 
tag. The electronic tag has several fields that the system automatically fills in. The 
automatic information may be obtained from the network user's user profile and 
network user's workstation. The network user has the option of filling in several 
fields to help him reference and/or identify the email message. The optional fields 
may include: client name, client number, project name, project number, the purpose 
of document and a field for notes (text). 

Block 701 represents the system 140 presenting a proposal form to the 
network user. The electronic tag may record and track all activity related to the 
electronic proposal and contract process. The network user may complete the 
electronic contract tag to register the name of the individual or organization that will 
receive a proposal. Next, the network user may be provided with a form of the 
organization's proposal. The network user may complete the proposal template. 
Upon completing the template, the network user may be prompted to save the 
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proposal. A copy of the proposal may be saved and registered in the electronic 
contract database 190. 

Block 702 represents the system 140 registering the proposal. The electronic 
contract database 190 maintains a record of the organization's electronic proposal 
5 and contract documents and their corresponding electronic tags. 

Block 703 represents the system 140 assigning an electronic tag to a 
proposal. 

Next, the network user may email the proposal to the prospect. Block 1004 
represents the system 1 40 presenting the email template to the network user. 

10 Block 705 represents the system 140 receiving a signal from the network 

user to send an email. 

The system 140 may automatically attach a cover document to the proposal 
to inform the prospect of the email proposal and the terms of electronic contracting 
with the offering organization. Figure 1 5 is a screen display illustrating an email 

1 5 proposal screen. Block 706 represents the system 140 attaching a contract terms 
document to the email message. A copy of the electronic tag is sent with the 
electronic proposal. Block 707 represents the system 140 recording the time and 
date the proposal email was sent to the prospect in the proposal's electronic tag. 
Block 708 represents the system 140 attaching a copy of an electronic tag to the 

20 email. 

System 140 may be configured so that, when the prospect opens the email 
proposal, an email reply with a copy of the electronic tag is sent to the offeror to 
confirm that the proposal was received and opened by the recipient. Figure 16 is a 
screen display illustrating an email proposal confirmation screen. Block 709 

25 represents the system 140 receiving the email auto reply. The system 140 records 
this activity in the electronic tag for the proposal stored in the electronic contract 
database 190. Block 710 represents the system 140 recording that the email 
proposal was received. The auto reply may be noted in the first line of the email 
message attached to the master electronic email proposal. 

30 If the prospect desires to accept the proposal, the prospect may be instructed 

to complete the attached proposal acceptance form. The proposal acceptance form 
has an attached electronic tag which records proposal information. Figure 17, Figure 
18, Figure 19 and Figure 20 are screen displays illustrating an email proposal screen. 
The proposal acceptance form may be emailed back to the offerer. Figure 21 is a 

35 screen display illustrating an email proposal signature screen. Block 711 represents 
the system 140 receiving an accepted email proposal. The system 140 may require 
that the proposal may only be returned to the offerer and the email address field may 
not be altered. Block 712 represents the system 140 activating the proposal email 
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message status. The proposal message status informs the offeror that an email 
proposal has been received. The network user typically may define how he wants to 
be notified by setting choosing from several message notification options from the 
message notify menu. For example, the network user may choose notification 
5 options that include notifying the offeror via an icon flashing on the screen, an icon 
flashing with a sound, or via an automated email message, or a pager number may be 
dialed by the system and a email contract waiting message tone or text message may 
appear on the offerer's pager. The electronic tag records the time and date the 
proposal entered the email system. Figure 22 is a screen display illustrating the 

10 email contract electronic tag screen. When the offeror opens the accepted proposal, 
the system typically automatically sends an email message to the prospect (i.e., 
client) to confirm that the proposal acceptance email message was received. Block 
713 represents the system 140 recording the proposal acceptance. Block 714 
represents the system 140 sending an email to prospect to confirm email proposal 

15 acceptance. Block 715 represents the system recording that the confirmation email 
was sent to the prospect. The proposal acceptance information may be recorded by 
the electronic tag. As soon as the electronic proposal is received by the offerer's 
email system, the system 140 typically alerts the offerer and sends an email reply to 
the prospect to confirm that the proposal was received. The electronic proposal 

20 email may be implemented to alert the network user that a proposal has been 

received such as, for example, by flashing a proposal icon on the network user's 
workstation. Block 716 represents the system 140 storing the accepted proposal. 
The system 140 may store the accepted proposal in the electronic contracts database 
190. 

25 In addition to the proposal tracking process, all contract and client-related 

correspondence may be tracked via email and/or documents stored in the central 
repository database 150. 

Watermark 

30 System 140 may be configured so that a watermark is used to authenticate an 

email message. In one embodiment of the system 140, a watermark may be a user- 
definable print feature which may be comprised of an image which is unique to an 
organization, business unit, department, branch or other segment of an 
organization's business. The watermark may also contain information that links the 

35 email to information contained in its electronic tag, which may include its reference 
code, the date the document was printed, the workstation the email form was sent 
from, who sent the email, and other user-definable fields to record system or user 
information. 

29 



BNSDOCID: <WO 002393 1A2_I_> 



WO 00/23931 



PCT/US99/24549 



Figure 4 is a flow diagram illustrating the process used by the system to print 
a document containing a watermark. The network user may choose to print a 
document containing a watermark. After the system 140 receives the print request, 
the system 140 may retrieve the email from the email records management database 
5 190. Block 401 represents the system 140 receiving the print request Block 402 
represents the system retrieving the email from the email records management 
database 190. The system 140 may retrieve the watermark image from a watermark 
database 200. Block 403 represents the system 140 retrieving a watermark image. 
Next, the system 140 may begin assembling a watermark. The system may 

10 read several fields from the email's electronic tag. Block 404 represents the system 
140 reading fields from the electronic tag. The minimal fields read may include its 
reference code, the date the document was printed, the workstation the email form 
was sent from, and who sent the email form. Additional user-definable fields may 
be read by the system 140. The system 140 may insert the reference code from the 

1 5 reference code field of the electronic tag into the image. Block 405 represents the 
system 140 inserting the reference code into the image. Next, the image may be 
placed in the email document. Block 406 represents the system 140 placing the 
image in the email document. Next, the email file with the watermark is sent to the 
printer to be printed. Block 407 represents the system 140 sending the email to 

20 printer. The information embedded in the watermark allows an end user the 

opportunity to track the printed document to the email's electronic tag stored in the 
central repository database 150. 

Email File Attachments 

25 The system may be configured so that files attached to email messages are 

also retained in the email records management database 1 80. It typically is 
important to store the file attachment with the email message in order to ensure 
proper record management. Each file attachment may be converted to an HTTP 
format. This will allow the system 140 to maintain a picture of the file. The system 

30 may also utilize file compression software, e.g., PKUNZIP, to compress the files to 
increase file storage space. 
Email Records Management Database 180 

The email records database 180 provides a method to index, record, and store 
business email messages sent from an organization and may act as method to 

35 authenticate email messages. As a policy all business email messages sent outside 
of an organization may be required to have a method to retain a copy of each 
message and a way to prove the message's authenticity. 
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After an email message has been assigned a reference code and is sent, the 
system 140 typically begins the process of recording the message in the email 
records management database 1 80. The business email's reference code, e.g., BEM, 
instructs the system 140 to automatically convert the text file format of the email 
5 message into a read-only format for storage in the central repository database 150. 
Next, the system 1 40 records a copy of the email message into the records 
management database 1 80 and copies the email message into the central repository 
database 150. This process allows an organization to retain a copy of all business 
email messages for their records. Email authentication is insured since the business 
10 email message was copied immediately after the network user stored or sent the 
email message. 

The email records database 180 utilizes the reference code from the email's 
electronic tag to index, store and record the email message in the database 1 80. The 
reference code assists the system in indexing the email into the correct master file. 
1 5 For example, the master file number may be 9082. The business email reference 
code may be BEM9082. The reference number tells the system to file the business 
email in the file with the master number 9082. 

The system 140 is typically configured so that most network users may not 
have access to the email records database 180 due to the fact that the purpose of the 
20 database 1 80 is to provide authentic records of the business email messages sent and 
received by the organization. A high level official within the organization may use 
an encryption key to access the email records within the system 140. 

Email Record Retrieval 

25 All business email may be indexed, stored and retrieved by its electronic tags 

and stored in the email records management database 1 80. The electronic tag, with 
its information fields, allows search engines to quickly retrieve messages from the 
central repository database 150. Figure 23 is a screen display illustrating an 
electronic tag screen. The network user searches the central repository database 150, 

30 such as with a web browser or other search tool. Electronic tags allow the system 

140 to maintain a historical record of an email message. An email's historical record 
begins when the email is first assigned an electronic tag and is registered in the 
document management system 1 35. An email's historical record is collected by the 
information recorded in an email's electronic tag. The electronic tag information is 

35 stored in the central repository. An email's electronic tag is typically not deleted 
from system 140 until the email is formally disposed of according to an 
organization's records management policy. 
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System 140 may be configured so that a document management Intranet web 
site may be used to access a related document's electronic tag information and 
document history. The network user typically has the option of filling in several 
fields to request information about a particular document. The screen user interface 
5 may be similar to a World Wide Web search engine interface. Figure 24 is a screen 
display illustrating a screen to request an email record. The user may have the 
option of completing as many or as few fields as he or she desires. An example of 
an existing search engine is Lycos on the World Wide Web. 

During a typical search, the system 140 searches the electronic tags in the 

10 central repository to obtain document information and returns the results to the 
network user. Figure 25 is a screen display illustrating a search engine interface. 
Figure 26 is a screen display illustrating a search engine interface. Once the email is 
retrieved, an email's electronic tag may appear on the screen. Figure 27 is a screen 
display illustrating an email report. A search for an electronic tag may produce 

1 5 several records including the document's access history including records of who 
last viewed the document and for how long, who extracted a copy of the document, 
who checked out the document, who returned the document, who removed the 
document, and any changes in electronic tags; information on all versions of a 
particular document; and any copying or migration processes leading to the current 

20 version, including the software used during the copying and migration process; the 
type of platform(s) and/or software used to reformat or convert the document as part 
of that migration; and the type of software package(s) used to alter or copy the 
document's content and machine- generated evidence, indicating any changes which 
were made to the document's content; the recovery process, including the date and 

25 time a backup copy was made, and the date and time of the recovery. This permits 
identification of any "window 1 in which an updated version of the document, now 
lost, could have been used. All documents with electronic tags may be stored on 
optical media, in a stand-alone system or a network environment, and can be 
dynamically accessed by the document title, information fields in the document's 

30 electronic tag or the electronic reference number through search engines. An 

example of an existing search engine is the Yahoo® system available from on the 
World Wide Web. Such search engines may be used to review all of the information 
in the central repository to match a document query. For example, a search can be 
made across multiple document types (series), limited to a particular document type 

35 or a group of document types and can use several search methods to focus on a 
particular value, field, date, text string or range of values, can combine several 
search methods, such as Boolean logic. Search strategies can be saved for future 
reference. 
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Policy makers, legal counsel and high level management of an organization 
typically are the only individuals who may have access to the email records 
management database 180. Pretty Good Privacy is an encryption key that is 
currently on the market and that is designed to insure the integrity and authenticity 
5 of the business email messages stored in the email records management database 
180. 

Automated Email Record Storage, Disposal and Purging 

The email records database 180 typically calculates the life cycle stage of all 
10 records, including email, and prints a record of all semi-active and final stage 

records so that they may be removed from active storage and placed on appropriate 
storage media such as secondary optional media or in a box for transfer off-site. 
Known products that manage records include Records Management Software 
available from QRMS. The process may be recorded in the policy effectiveness 
1 5 module 1 40 and stored in the email records management database 1 80. The system 
140 may prompt the system administrator via email and may identify the documents 
that are to be eliminated, purged and/or are no longer needed for any legal, 
operational, or other purpose. 

20 Print, Access and Viewing Options 

The system 140 may be configured to provide for various email print options 
including Electronic Tag Only, Email Only, and Email with Tag, No Print, No 
Access, Limited Access, No Viewing, Email with file attachment and typically are 
detailed in the print option section of the document management system 135. This 
25 process is similar to printing documents in a word processing system such as the 
Microsoft Word word processing system available from Microsoft Corporation. 

When printing from the email records management database 1 80, network 
users may be required to have an encryption key, such as the Pretty Good Privacy 
system mentioned earlier. 

30 

Email Records Retention 

Typical email systems enable users to delete messages from the "in-box", but 
the email messages are likely stored on one or more file servers and backup tapes. 
Records retention software such as RetentionManager available from Skupsky 
provides for the tracking and automating records retention by the system 
administrator. The email compliance system 140 may be configured to 
automatically reminds the system administrator to execute records retention 
procedures in the email records retention module. The email records retention 
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module typically provides system administrators with a checklist of procedures to 
execute as part of managing the system 140. Figure 28 is a screen display 
illustrating an email records retention notice. The system administrator usually may 
not bypass the tasks within the system 140 such as purge the messaging system, 
properly dispose of internal messaging records and media, backup/archive (time 
field can be chosen) email server messages to tape/media, label and date email 
tape/media, register new email tape/media in the system's tape archive database, 
indicate the storage and location of newly archives email tape/media, and the proper 
dispose procedures of archived email tape/media. If the system administrator 
continues to ignore reminders related to such tasks, the email management system 
140 preferably requires the system administrator to execute the tasks in order to 
proceed with the use of the system. 

After the system administrator has followed the instructions, the system 
administrator is prompted to log into email compliance system 140 and complete the 
record retention report form to confirm each step has been completed. Figure 29 is a 
screen display illustrating a records retention confirmation report. The email 
compliance system 140 may send email messages to the LAN Administrator and a 
policy officer if the system administrator fails to execute retention procedures and/or 
complete retention reports. The email compliance system 140 has several technical 
support options to access in-house tech support via telephony, email message, fax, or 
telephone. 

The foregoing description of the embodiments of the present system have 
been presented for the purposes of illustration and description. It is not intended to 
be exhaustive or to limit the invention to any particular form disclosed. Many 
modifications and variations are possible. It is intended that the scope of the 
invention be limited only by the following claims. 
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WHAT IS CLAIMED IS: 

1 . A method for managing an electronic record in a distributed computing 
environment, comprising the steps of: 

creating an electronic tag that uniquely identifies an electronic record; 
storing the electronic tag; and 
distributing the electronic record. 

2. The method of claim 1, further comprising the step of purging the electronic 
record comprising the steps of deleting the electronic record and selectively deleting 
the electronic tag. 

3. The method of claim 1 , wherein the storing step further comprises the step of 
storing the electronic record. 

4. The method of claim 1 , wherein the distributing step further comprises the 
step of selectively determining whether the recipient may purge the electronic 
record. 

5. The method of claim 1 , wherein the distributed computing environment 
comprises computers having a registry and a user profile, wherein the creating step 
comprises the steps of: 

analyzing a network user's workstation specifications; 
analyzing a network user's user profile; and 

generating a reference code, wherein the electronic tag is generated from 
information analyzed in the network user's workstation specification, the network 
user's user profile, and the reference code. 

6. The method of claim 1, wherein the creating step further comprises the steps 
of: reading stored electronic tags; and 

generating an electronic tag in response to accessing an electronic record. 
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7. The method of claim 5, wherein the generating step further comprises the 
steps of reading the electronic record. 

8. The method of claim 5, wherein the reference code comprises a classification 
5 code and an index code. 

9. The method of claim 8, wherein the classification code is selected from a 
group comprising business email, personal email, intramail, bulletin board, 
minutemail, and purgemail. 

10 

10. The method of claim 8, wherein the index code identifies the contents of an 
electronic record and the sender or recipient of the electronic record. 

1 1 . The method of claim 1 , wherein the electronic record is an email message. 

15 

12. The method of claim 1 , wherein the distributing step comprises the steps of: 
reading the electronic tag; and 

generating a new electronic tag based on the electronic tag, wherein the 
generating step comprises the steps of reading a network user's workstation 
20 specifications, reading a network user's user profile, and generating a reference 
code. 

13. An apparatus for managing electronic records on a in a distributed 
computing environment, the apparatus comprising: 
25 a computer system comprising at least one processor and at least one 

memory, the computer system being adapted and arranged for: 

creating an electronic tag that uniquely identifies an electronic record; 

storing the electronic tag; and 

distributing the electronic record. 

30 
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14. The apparatus of claim 13, wherein the computer system is further 
adapted and arranged for purging the electronic record wherein the computer system 
deletes the electronic record and selectively deletes the electronic tag. 

15. The method of claim 13, wherein the computer system is further 
adapted and arranged for selectively determining whether the recipient may purge 
the electronic record. 

16. The method of claim 13, wherein the distributing computing 
environment comprises computers having a registry and a user profile, wherein the 
computer system is configured and arranged for: 

analyzing a network user's workstation specifications; 
analyzing a network user's user profile; and 

generating a reference code, wherein the electronic tag is generated from 
information analyzed in the network user's workstation specification, the network 
user's user profile, and the reference code. 

17. An article of manufacture for managing electronic records in a 
distributed computing environment, the article of manufacture comprising a 
computer-readable storage medium having a computer program embodied therein 
that causes the computer network to perform the steps of: 

creating an electronic tag that uniquely identifies an electronic record; 
storing the electronic tag; and 
distributing the electronic record. 

18. The article of claim 17, further comprising the step of purging the 
electronic record comprising the steps of deleting the electronic record and 
selectively deleting the electronic tag. 

19. The article of claim 1 7, wherein the storing step further comprises the 
step of storing the electronic record. 
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20. The article of claim 1 7 wherein the distributing step further comprises 
the step of selectively determining whether the recipient may purge the electronic 
record. 

5 21 . The article of claim 17, wherein the distributed computing 

environment comprises computers having a registry and a user profile, wherein the 
creating step comprises the steps of: 

analyzing a network user's workstation specifications; 

analyzing a network user's user profile; and 
10 generating a reference code, wherein the electronic tag is generated from 

information analyzed in the network user's workstation specification, the network 
user's user profile, and the reference code. 

22. The method of claim 1 7, wherein the creating step further comprises the 
15 steps of: 

reading stored electronic tags; and 

generating an electronic tag in response to accessing an electronic record. 
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Anoxea, 

Attached is a cover letter explaining our e— proposal and contract 
policies, procedures and terms. Please review the attachment carefully 
and contact us if you have any questions or concerns. 

We 1 ook forward to working with you. 



JaneJones 
Account Manager 
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E— Proposal 



Virtual Workspace 

Technological advances in the workplace are allowing organizations to connect 
with employees, business associates and clients in a more efficient manner. 
However, many organizations are dscovering their communications technology 
is advancing much foster than their corporate policies and their personal 
understanding of the appropriate use of electronic communications. 

Virtual Workspace closes this gap in the electronic communication cycle by 
guiding organizations toward improving their techniques while reducing the risk 
and liability associated with online interactions. Working through end-user 
education seminars - such as E-mail Style & Etiquette and Virtual Policy 
Builder - as well as through direct communication products and consulting 
services, Virtual Workspace offers enterprise-wide, ethical solutions to 
electronic communication challenges. 
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E-mail Style & Etiquette 

/4-day seminar 

The complete integration of electronic communication into today's business 
infrastructure has changed the cycle of business correspondence. In addition 
to being a new form of communication, E-mail has created a sense of 
immediacy and responsiveness among users. Together, these factors have 
contributed to a lack of defined business communication standards for 
electronic correspondence. 

Through the E-mail Style & Etiquette training program, employees learn 
guidelines for writing effective E-mail, including the use of proper salutations 
and grammar, and other business communications standards that are often 
overlooked in the electronic age. 
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Virtual Policy Builder 

V£-day seminar 

Many consider E-mail messages to be the equivalent of electronic personal 
conversations. However, unlike most forms of personal conversation, E-mail 
documents have been deemed by state and federal courts as special forms of 
computer records that are admissible in court. Even if the content of these 
messages are solely the opinion of the sender, the court may consider the 
messages to reflect the views of the organization as a whole. 



Virtual Policy Builder, an E-mail ethics and policy training program, helps 
organizations limit liability and improve employee competency through the 
creation of E-mail policy guidelines. Since these guidelines are created from 
employee feedback obtained during the Virtual Policy Builder seminar, the 
creation of these guidelines is, in itself, an exercise in connecting through 
communication and technology. The result of this connection is a employee- 
backed, customized policy that ensures the integrity of the electronic 
communications disseminated from an organization's office. 
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Email Records Maintenance Checklist 

(hypert inked checklist) 

Purge trie messaging system 

Property dispose of internal messaging records and mecfia 
Backup/archive (time field can be chosen) email server messages to 
tape/meda 

Label and date email tape/meda 

Register new email tape/media in the system's tape archive database 
Indicate the storage and location of newly archives email tape/media 
Properly dispose of archived email tape/media 

The system will keep reminding you to execute activities in the records retention 
module. If you bypass the tasks within the system and continue to ignore the 
reminders, the system will eventually require you to execute the task in order to 
proceed with the use of the system and your computer. 
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